Linux 6.12 added a check in fs/fuse/inode.c:process_init_reply that
requires FUSE_POSIX_ACL to be present whenever FUSE_ALLOW_IDMAP is
advertised. Without it, the kernel sets conn_error = 1, silently
degrading the virtiofs connection. In this degraded state, reading and
modifying existing files still works, but creating new files or
directories fails with EPERM.

This breaks any setup where the host user's GID doesn't match the guest
user's GID (e.g., host 1000:1001 vs guest 1000:1000), because the
idmapped mount that would translate GIDs never gets established.

The root cause was that ALLOW_IDMAP was advertised from the server-global
"supported" flags in server.rs, which meant it got enabled regardless of
whether the backend could actually fulfill the POSIX_ACL contract that
the kernel now requires alongside it.

The fix moves ALLOW_IDMAP out of the server-global supported mask and
into each passthrough backend's init() return value, coupled with
POSIX_ACL. Now the negotiation looks like this:

  1. If the kernel is capable of POSIX_ACL and the backend has xattr
     support enabled, advertise POSIX_ACL.
  2. Only then, if the kernel is also capable of ALLOW_IDMAP, advertise
     ALLOW_IDMAP alongside it.

This works for passthrough filesystems because the POSIX_ACL contract
(mode-ACL synchronization, default ACL inheritance, ACL xattr storage)
is fulfilled by the host kernel. The passthrough already forwards all
xattr operations, including system.posix_acl_access and
system.posix_acl_default, directly to the host via libc calls with no
namespace filtering.

Note that on kernels 6.2+, the FUSE VFS layer has fuse_get_acl() and
fuse_set_acl() inode operations that handle idmapped UID/GID translation
within ACL entries, so the passthrough server doesn't need to interpret
ACL binary data itself.

Both the Linux and macOS passthrough backends are updated with the same
logic so we don't regress macOS-hosted Linux guests.

Fixes: containers#568
Signed-off-by: Juan Antonio Osorio <ozz@stacklok.com>